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The Profile Naming Service 



LARRY L. PETERSON 
University of Arizona 



Profile is a descriptive naming service used to identify users and organizations. This paper presents 
a structural overview of Profile's three major components: a confedration of attribute-based name 
servers, a name space abstraction that unifies the name servers, and a user interface that integrates 
the name space with existing naming systems. Each name server is an independent authority that 
allows clients to describe users and organizations with a multiplicity of attributes; the name space 
abstraction is a client program that implements a discipline for searching a sequence of name servers; 
and the interface provides a tool with which users build customized commands. Experience with an 
implementation in the DARPA/NSF Internet demonstrates that Profile is a feasible and effective 
mechanism for naming users and organizations in a large internet. 

Categories and Subject Descriptors: C.2.4 [Computer Communication Networks]: Distributed 
Systems — distributed applications, distributed databases; D.2.2 [Software Engineering]: Tools and 
Techniques — user interfaces; H.2.4 [Database Management]: Systems— distributed systems; H.3.3 
[Information Storage and Retrieval]: Information Search and Retrieval— search process, selection 
processes; H.3.4 [Information Storage and Retrieval]: Systems and Software — information net- 
works, question-answering (fact retrieval) systems 

General Terms: Design 

Additional Key Words and Phrases: Attribute -based naming, white-pages service 



1. INTRODUCTION 

Profile is an attribute-based (descriptive) naming service for a large internet. It 
takes as an argument a set of attributes that describe a user or an organization 
and returns information about the resources associated with the entity identified 
by the attributes. Such a system is commonly said to provide a white-pages 
service. Profile is motivated by, and implemented in, the DARPA/NSF Internet 
[12, 21]. An important characteristic of such an internet is that it spans a 
collection of autonomous systems, each of which provides its own mechanism for 
naming resources. For example, a file name is meaningful in some file system, a 
host name is resolved by a host naming system, and mailbox addresses are 
understood in the mail system. Names defined in these systems are often difficult 
for users to discover for the first time and equally difficult to remember if used 
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infrequently. Profile is a supplemental naming service that augments existing 
naming systems; users consult it to learn the names of resources. 

Profile is based on the architecture schematically depicted in Figure 1. The 
fundamental object supported the architecture is the principal : a user or organi- 
zation that sponsors a collection of internet resources. For a principal to sponsor 
a resource implies that the principal owns, manages, or is somehow responsible 
for the resource. 1 For example, a principal might sponsor a mailbox, workstation, 
home directory, one or more printing devices, or a file system. Of the resources 
sponsored by principals, the one most important to Profile's architecture is the 
name server: a network server that takes as an argument a set of attributes 
describing one or more principals and returns information about the principals 
identified by the attributes. We say a name server is a naming authority for the 
set of principals whose names it is able to resolve. 

For example, an internet site might constitute a principal that sponsors a name 
server. Such a name server would be a naming authority for the user, project, 
and role principals resident at the site. As another example, a mailing list, a 
users group, or a special interest group might sponsor a name server that is a 
naming authority for the group's members. One could also imagine an internet 
principal that sponsors a name server identifying those principals that sponsor 
a Profile name server. Finally, a user principal might sponsor a name server that 
is a naming authority for those principals whose resources the user frequently 
accesses. Such a name server is referred to as the user's alias name server. 

Profile does not enforce a specific configuration, such as a hierarchy, on a 
collection of name servers. Instead, any principal can sponsor a name server and 
each such name server can be a naming authority for any set of principals. A 
name server that is an authority for principal p is said to be linked to a name 
server sponsored by principal p if, when asked to resolve a name for p, the former 
server returns the address of the latter server. For example, when asked to resolve 
the name of an organizational principal, the internet principal's name server 
might return the address of the organization's Profile name server. Intuitively, 
name servers are viewed as forming a loosely coupled confederation. Profile 
supports a name space abstraction that unifies this confederation by providing a 
mechanism for searching a sequence of name servers. The name space is not 
explicitly embedded in the individual name servers, but rather is implemented as 
a client program that takes advantage of links between servers. 

Finally, Profile provides a user interface that integrates the Profile name space 
with the rest of the internet's naming systems. The interface provides a proce- 
dure-based tool with which users build customized commands. 

This paper makes two major contributions. First, it gives a structural overview 
of the Profile naming service: Section 2 describes Profile name servers, Section 
3 defines the name space abstraction, and Section 4 introduces the interface 
mechanism. Second, it discusses several issues associated with providing attrib- 
ute-based naming systems and evaluates the techniques employed by Profile to 
address those issues. This discussion is presented in Section 5. 



1 Although we borrow the term "principal" from the computer security literature [23], we are interested 
in identifying principals in an effort to learn the names of their resources, not in how the system 
protects those resources. 
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User Interface 




Fig. 1. Profile's architectures. 



2. NAME SERVERS 

A Profile name server is a naming authority for a set of principals, denoted P. A 
name server consists of three components: a database of attributes for the 
principals in P, a suite of interpret functions, and some database management 
tools. A client program running on behalf of a user contacts a name server and 
requests that a certain interpret function be applied to a given set of attributes, 
the interpret function computes the subset of principals in P identified by the 
attributes, and the name server returns the set of attributes it possesses for each 
identified principal. The client and name server communicate according to a 
specific protocol [4], 

2.1 Attributes 

An attribute is a syntactic entity of the form tag— value that denotes a property 
or characteristic of a principal. For example, 'mail=jxd@state.edu\ 'name=John 
Doe\ *phone=621-1234' and *login=jxd' are attributes that describe a user prin- 
cipal. A name server's database binds a set of attributes to each principal pEP. 

\attribute lf attribute.^, ...)—► p. 

Each attribute bound to a principal is said to be registered for that principal. In 
the abstract, there also exists a possibly infinite set of attributes that describe 
each principal. A name, denoted N — [attribute lf attribute 2y . . . ), is a finite set of 
attributes submitted by a user to identify one or more principals. 

Intuitively, the attributes bound to a given principal correspond to both 
"external" identifiers for the principal — for example, personal name, phone 
number, postal mail address— and "internal" identifiers for the resources spon- 
sored by the principal — electronic mail address, workstation name, login id. 
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Thus, while it might seem more natural to present a person's name to a Profile 
name server to learn his or her mailbox address, it is equally possible that a user 
might query a Profile name server with a mailbox address to learn a user's 
personal name. All attributes simply denote properties of principals. 

Profile represents each attribute by an expression that defines a language over 
the alphanumeric characters, the blank character, and select special characters. 
Briefly, the operators that may be used to compose an attribute include alteration 
(|), optional substring ([ ]), zero or more character wildcard (*), and a single 
character wildcard (?); the full grammar for an attribute is given in the appendix. 
For example, the attribute ' John | [ J [ohn] ]Doe' denotes the set of strings * John', 
'John Doe', ' J Doe', and 'Doe'. 

The attributes registered in the database must denote a finite set of 
strings and include the attribute tag as an optional prefix; e.g., 
*[name=] John) [ John]]Doe' might be registered for principal John Doe. Attri- 
butes given in a name may take advantage of the full expressive power of the 
language, including the ability to denote an infinite number of strings. Typically, 
attributes given in names are simple expressions; e.g., 'John', '627-1234', **Doe\ 
Each attribute returned by a name server is a canonical form of the registered 
attribute; e.g., *name=John Doe', *mail=jxd@state.edu'. Based on its tag, a client 
may select an attribute from the set returned by a name server and use its value 
as a resource name that is meaningful in some other naming system. 

A pair of attributes, for example one given in a name and one registered in the 
database, are considered equal if the intersection of the set of strings denoted by 
each is nonempty. Given this weak definition of attribute equality, a single 
attribute can be taken to represent different properties. For example, the attribute 
*S*' might denote both a name and an address. 

Profile defines a set of well-known attribute tags: 

name principal's name 

address principal's postal mail address 

phone principal's phone number 

mail principal's electronic mailbox address 

login user principal's login identifier 

home name of host on which principal's 

home directory resides 
domain principal's local domain name 
profile address of principal's attribute-based 

name server 

handle unique attribute by which principal can be 
identified in this name server 

Additional attribute tags may also be included in a name server. Note that not 
all attribute tags are used for all principals. For example, the login tag is only 
meaningful for a principal that corresponds to a user, while the profile tag is 
only meaningful for a principal that sponsors a Profile name server. Also, each 
principal need not have the full set of attribute tags bound to it in the name 
server. For example, a user principal might have a postal mail address but no 
phone number in the database. Finally, multiple attributes with the same tag 
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may be bound to a single principal, denoting multiple instances of the same 
resource; e.g., multiple mailboxes, replicated Profile name servers. 

2.2 Interpret Functions 

Profile supports a family of interpret functions, each of which computes the set 
of principals identified by a given name according to the attributes registered in 
the name server's database. The interpret functions are described in intuitive 
terms for the purpose of this paper. A companion paper develops a theoretical 
framework for reasoning about naming systems as specialized inference mecha- 
nisms [5]. The theory is used to characterize a class of descriptive naming systems 
that includes Profile. The class is less restrictive than conventional naming 
systems, but more specialized than general databases. 

Mapping sets of attributes onto principals is nontrivial for four reasons. First, 
one attribute may describe many principals. Second, some attributes in the name 
server's database may not correctly describe the principals for which they are 
registered. Third, not all attributes that describe a given principal are registered 
for that principal. Finally, users may submit attributes that do not describe the 
principal they were intended to describe. We say that an attribute is ambiguous 
if it describes more than one principal and an attribute is invalid if it does not 
describe a particular principal but is either registered for the principal or given 
in a name for the principal. Profile's interpret functions are based on the following 
definitions. 

First, the set of attributes registered in the name server's database is partitioned 
into complete and incomplete subsets: an attribute registered for principal p is 
complete if and only if (i) it describes p, and (ii) it is registered for all principals 
in P it describes. All other attributes are incomplete. Note that the second 
condition for completeness corresponds to the closed world assumption in logic 
databases [22], Clearly, an interpret function cannot reliably use incomplete 
attributes. One reason, of course, is that incomplete attributes may be invalid. A 
second, and in practice, more likely reason is that an incomplete attribute may 
be registered for one principal it describes, but not another. To see the significance 
of this second point, consider attributes a and b, both of which describe principals 
p and q. Suppose a is registered for both principals but b is registered only for p; 
that is, a is a complete attribute and b is an incomplete attribute. If a user names 
a principal with the attributes a and b, then it is intuitively wrong to not return 
q simply because attribute b is not registered for it; name {a, b\ describes both 
principals equally well. 

Second, an attribute in name N is considered a candidate if and only if the 
attribute is registered for some principal in P. For example, suppose the name 
server's database contains the following two bindings 

{a, 6, c) -*p 

|a, b, d \ -> q. 

Name {a, c, d, e) contains the candidate attributes a, c, and d. Intuitively, 
noncandidate attributes are either not registered for the principal they describe 
or they are invalid. Furthermore, a set of candidate attributes is partitioned into 
two disjoint subsets, called the complete candidate name and the incomplete 
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interpret\{N) 

Fig. 2. Definition of interpret,. ^ rehirn(cp(N) U ip(N)); 

} 

candidate name, based on whether each attribute is in the complete or incomplete 
partition of registered attributes, respectively. 

Third, for any two sets of attributes— e.g., a complete candidate name and the 
set of complete attributes registered for a principal — the first set is said to exactly 
match the second set if and only if the former set is totally contained in the latter 
set, and partially match if and only if the intersection of the two sets is nonempty. 
For example, the candidate name [a, b, d } exactly matches the set of registered 
attributes \a, b, c, d\, but the candidate name {a, c, e) only partially matches 
{a, 6, c> d}. In other words, Profile defines two standards for determining the 
equality of a set of attributes in a name and a set of attributes registered for a 
principal — exact match and partial match — both of which are weaker than set 
equality. 

Thus, for name N and a set of bindings for principals in P, with the attributes 
registered for each principal partitioned a priori into complete and incomplete 
subsets, we can define the following four sets: 

ce(N) s the subset of principals in P whose complete attributes are 
exactly matched by the complete candidate name; 

ie(N) se the subset of principals in P whose incomplete attributes are 
exactly matched by the incomplete candidate name; 

cp(N) s the subset of principals in P whose complete attributes are 
partially matched by the complete candidate name; 

ip(N) s the subset of principals in P whose incomplete attributes are 
partially matched by the incomplete candidate name; 

Note that the set of principals exactly matched by a complete (incomplete) 
candidate name is a subset of the partially matched principals; i.e., ce(N) Q 
cp(N) and ie(N) Q ip(N) for all N. Also, if ce(N) is empty but cp(N) is not, 
then the user must have submitted invalid attributes for the intended principal. 

Profile provides four interpret functions, each of which defines an increasingly 
restrictive (discriminating) interpretation of what principals are named by a set 
of attributes. The least restrictive, called interpret^ and given in Figure 2, 
computes the disjunction of the attributes contained in the name. 

Loosely speaking, the second and third functions compute the conjunction of 
the attributes in the given name, thereby allowing the user to identify some 
particular principal. Interpret^, as illustrated in Figure 3, gives priority to com- 
plete candidate names over incomplete candidate names and exact matches over 
partial matches. For a name that contains a nonempty complete candidate name 
and no invalid attributes, the set of principals returned by interpret^ is guaranteed, 
by definition, to include the intended principal. 

Interprets, as given in Figure 4, also prefers complete attributes to incomplete 
attributes and exact matches to partial matches. Interpret^ is more restrictive 

ACM Transactions on Computer Systems, Vol. 6, No. 4, November 1988. 



The Profile Naming Service • 347 



interpretiifi) 

{ 



if (|ce(N)|>0) 

return (ce(N)); 

if ( |cp(N)| > 0) 

return (cp(N)); Flg " 3 ' Defimt,on of interpret. 

if(|ie(N)|>0) 

return (ie(N)); 

return (ip(N)); 



interprets^) 

^ if ( |ce(N)| = 1) 

return (ce(N)); 

if (|ce(N)nie(N)| >0) 

return (ce(N) n ie(N)); 

if ( |ce(N) n ip(N)| > 0) 

return (ce(N) n ip(N)); 

if ( |ce(N)| > 0) 

return (ce(N)); 

if (|cp(N)nie(N)| >0) 

return (cp(N) n ie(N)); 

if (|cp(N)nip(N)|>0) 

return (cp(N) n ip(N)); 

if ( |cp(N)| > 0) 

return (cp(N)); 

if ( |ie(N)| > 0) 

return (ie(N)); 

return (ip(N)); 

} 

Fig, 4. Definition of interprets 

than interpret z , however, because it uses incomplete attributes to narrow the set 
of returned principals. If N contains no incomplete attributes, then interpret^ 
returns exactly the same set of principals as interprets It cannot, however, 
guarantee that the intended principal is returned if N contains an incomplete 
attribute. 

Finally, interpret* given in Figure 5 uses ce(N) to match at most one principal 
Intuitively, interpret 4 implements the lookup function provided in many conven- 
tional directories; it fails when the name is ambiguous. 
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interpret^) 

{ i£(|ce(N)i = l) 

Fig. 5. Definition of interpret*. return (cc(N)); 

return (0); 

} 



To see the distinction between the four interpret functions, consider a database 
that contains the bindings 

{John, Smith, systems) -+ js 

(John, Doe) — ► jd 

{Mary, Smith, theory) — > ms 

where attributes 'John', 'Mary', 'Smith', and 'Doe' are complete, attributes 
'systems' and 'theory' are incomplete, and js, jd, and ms denote three different 
principals. (The policy for determining which attributes are complete and which 
are incomplete is discussed in Section 2.3.) When applied to the name {Harry, 
Smith}, the first three interpret functions return js and ms and interpret 4 returns 
the empty set; when applied to the name {Mary, Smith}, interpret^ returns js and 
ms, while the last three interpret functions return only ms; and when applied to 
the name {John, systems}, interpret^ returns js and jd, interpret^ returns only js, 
and interpret* returns the empty set. 

A final note: If there exists a subset of complete attributes registered for a 
particular principal that does not exactly match the complete attributes registered 
for some other principal — i.e., the principal's name is not "hopelessly" ambigu- 
ous — then it is possible to construct a name such that interpret 2f interpret^, and 
interpret* return only that principal. To guarantee this property, as well as to 
provide an attribute-based name for each principal that is likely to match exactly 
the same principal for multiple queries of a name server, each Profile name server 
defines at least one unique attribute for each principal. This unique attribute has 
the tag handle. 

2.3 Database 

In most ways, a Profile name server database is managed like any other name 
server database [3]. This section briefly considers those database issues that are 
unique to Profile. A more detailed discussion of the implementation can be found 
in [4]. 

From an operational perspective, a name server's database exists in two forms. 
A text version contains a set of complete and incomplete attributes for each 
principal in P. The text version is created and updated by users. An internal 
version of the database is used by the interpret functions. The internal version 
is compiled from the text version by translating the set of registered attributes 
into a finite state automata. The name server is restarted periodically so that the 
internal version of the database reflects changes to the text version. 

The text version of the database is divided into protected and unprotected 
partitions. The protected partition consists of the complete attributes for each 
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principal in P. The protected partition can only be updated by a privileged 
administrator. It is the responsibility of this administrator to ensure that the 
complete attributes registered in the database satisfy the definition of complete- 
ness; i.e., that they are correct and that an attribute registered for one principal 
is registered for all principals it describes. Satisfying the first part of this 
definition assumes the correctness of information given the privileged adminis- 
trator by individual principals; an assumption we find acceptable. A sufficient, 
but not necessary, condition for guaranteeing the second part of this definition 
is to register all attributes with a given tag; e.g., all phone numbers, all personal 
names. 

The exact way in which the protected partition of the text version is maintained 
depends on the set of principals for which the name server is an authority. 
Consider, for example, a Profile name server sponsored by an internet site for 
which P is the set of individuals, roles, and projects within the site. Complete 
attributes for these principals can be automatically generated from existing 
administrative data. The prototype implementation in UNIX®, for example, uses 
an awk script [1] to generate the set of attributes 

( [login=J jxd, [name=]John| [J[ohn]]Doe, 

[office=]320, [phone=][(621|Xl|xl)[-| ]]1234, [mail=]jxd@state.edu) 

for user John Doe from the mail alias file /usr /lib/aliases and the /etc/passwd 
entry 

jxd;r4zqXMNgxssyM:75:20:John Doe,302UCC,1234:/usrl/jxd:A>in/csh 

As another example, a special interest group or a users group might generate a 
text database from its membership list. Note that, in both cases, the attribute 
generation mechanism is reexecuted periodically (i.e., daily) to incorporate 
changes in the administrative data. Section 3 describes an alternative mechanism 
used by individuals to maintain alias name servers. 

The unprotected partition of the database contains incomplete attributes for 
each principal. Principals are allowed to modify the unprotected information 
bound to them in the text version of the database. For example, a user could 
enter additional attributes that might help others identify the user (e.g., nick- 
names, areas of interest, current projects), as well as attributes that correspond 
to additional resources associated with the principal (e.g., printer, workstation). 
Attributes registered in this manner must be treated as incomplete. This is 
because there is no guarantee that all users will register a particular attribute. 
There is also no guarantee that the attributes are correct; i.e., one user might 
masquerade as another by entering the other user's attributes. Protection mech- 
anisms available in the local system are used to ensure that a given user has the 
appropriate permission to modify the information bound to a given principal; 
e.g., a user can modify his or her own binding. 

Note that even though an organization supports a single name server that is 
an authority for all the user principals within the organization, the administration 
of the name server's text database might be distributed over a hierarchy. For 
example, each department in a university might maintain a text database for its 



° UNIX is a trademark of Bell Laboratories. 
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own users, with the resulting set of text databases merged to generate a single 
internal database for the university's name server. Also, a principal is free to 
replicate name servers. That is, a principal might implement a set of name servers 
on distinct hosts, each of which is an authority for the same set of principals and 
each of which is initialized from the same text database. Finally, allowing users 
to modify the unprotected partition of the database is best suited for a site-based 
name server where local users have more convenient access to the database. A 
name server sponsored by a special interest group, for example, might implement 
only the protected partition and offer a name server supporting only complete 
attributes. 

3. NAME SPACE 

A name space abstraction unifies the confederation of name servers. It provides 
an extended syntax for specifying attribute-based names, called a profile name, a 
discipline for contacting a multiplicity of name servers, and a mechanism for 
maintaining an alias name server. The name space is implemented as a client 
program that takes advantage of profile attributes returned by one name server 
that give addresses of other name servers. Note that allowing any name server 
to have a link to (capability for) any other name server, thereby resulting in a 
nonhierarchical confederation name space, is not new to Profile. Such name 
space organizations have been used successfully in other computing systems as 
well [2, 15, 25]. What makes searching the name space more difficult in Profile 
is that the name being resolved at any given name server may yield multiple 
links (capabilities). 

The name space supports two operations, resolve and bind. Resolve takes as an 
argument a profile name and returns the set of attributes associated with each 
principal identified by the name. Three parameters defined in a client's environ- 
ment control the operation of resolve: a search path specifies the sequence of 
name servers to be contacted to resolve the name; a default interpret function 
defines the interpret function that is to be applied at each name server; and a 
search strategy specifies one of four possible disciplines for resolve. The elements 
of the search path are name server addresses known a priori by the client, the 
interpret function is given by a string that denotes the function, and the search 
strategy is expressed as a product of two orthogonal options: (i) find the first or 
find all results, and (ii) follow links under explicit or implicit control. 

In its simplest form, the profile name taken as an argument by resolve is a 
string consisting of one or more attributes separated by delimiters; e.g., * John 
Doe, 621-1234, State University'. We call this an attribute-based name. In 
addition, a profile name may contain two or more attribute-based names sepa- 
rated by an indirection operator '@' and an alternation operator * | '; e.g., 'John 
Doe, 621-1234 @ State University' and 'John Doe, 621-1234 @ (State Univer- 
sity | Sigcomm)'. Also, a string denoting an interpret function may be explicitly 
applied to an attribute-based name; e.g., 'John Doe, 621-1234 @ interpretl (State 
University)'. Finally, a profile name may contain multiple '@' and ' | * operators, 
where '|' has precedence over '@', * | * is left associative, and *@' is right 
associative. 
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To illustrate how resolve operates on the four example profile names given in 
the previous paragraph, consider the following parameter settings. Suppose a 
user knows that the local site's name server is located on the host named 
'megaron', the interpret principal sponsors a name server that resides on the 
host named 'sri-nic.arpa', and a special interest group to which the user belongs 
sponsors a name server on host 'venera.isi.edu'. 2 The user might specify the 
search path 

(alias, megaron, sri-nic.arpa, venera.isi.edu), 

where 'alias' is a label for the user's alias name server. Also assume the user 
defines interprets as the default interpret function and specifies a "find the first 
answer under explicit control" search strategy. 

Given this environment, the first profile name is interpreted at each name 
server in the search path, in order, until one of the name servers yields a 
nonempty result. In the case of the second profile name, the attribute-based 
name to the left of the ( @' is interpreted at the name server sponsored by each 
principal identified by the attribute-based name to the right of the *@\ The later 
name is interpreted according to the search path. Should the rightmost attribute- 
based name yield a profile attribute for more than one principal, then resolve 
contacts the name server sponsored by each such principal to interpret the 
leftmost name and the union of the results from each name server is returned. 
The third example name causes the leftmost attribute-based name to be resolved 
at the name server sponsored by the principal(s) identified by 'State University* 
and the principal(s) identified by 'Sigcomm'; both attribute-based names right 
of the *@' are interpreted independently according to the search path. The final 
profile name uses interpret to resolve the rightmost name and the default 
interpret function to resolve the leftmost name. 

Now consider how alternative parameter settings vary the resolution process. 
First, by setting the search strategy to look for all results rather than the first 
result, a profile name is interpreted at all name servers identified in the search 
path and the union of results returned from each server is returned to the client. 
An alternative proposed by Sollins that generalizes the " first" and "all" strategies 
is to let the search path be a partial order [25]. 

Second, by setting the search strategy to implicitly follow links, resolve auto- 
matically contacts any name servers identified in a result yielded by a query of 
another name server; i.e., both the *@' and ' | * operators are unnecessary. In other 
words, using this search strategy to resolve the name 'John Doe, 621-1234, State 
University, Sigcomm' usually yields the same results as the third example given 
above. It may, however, yield unexpected results. For example, if the search 
strategy is also set to look for the first result and John Doe is the name of a local 
principal, then resolve will return information about the local John Doe and not 
one at State University or at Sigcomm. An even more subtle possibility is that 
the user intends for attributes 'State University' and 'Sigcomm' to identify a 
principal at the internet principal's name server and for 'John Doe' and '621- 
1234' to yield a result at each of those principals' name servers, while in fact 

2 This example is for illustrative purposes only. 
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' John Doe' yields a result at the internet name server (perhaps it is the name of 
a company) and 'State University' identifies a principal known in John Doe's 
name server (perhaps John Doe the company has an affiliation with State 
University). It is also possible that following links under implicit control results 
in a loop; i.e., one name server being contacted multiple times to resolve the same 
name. Such loops are detected and broken by the client program that controls 
the search. 

In addition to resolving profile names, the name space bind operation provides 
an interface to the user's alias name server. It takes as arguments a set of 
attributes and adds an entry containing the attributes to the user's alias name 
server. Typically, the set of attributes are given by an "alias" attribute and the 
result of calling the resolve operation. For example, 

bind Cjohn', resolve^ John Doe, routing, Sigcomm')) 

adds an entry containing 'john' and the attributes returned by resolve to the 
user's alias name server. 

We conclude this section with several comments. First, while it is tempting to 
think of the internet principal's name server as the root of a hierarchy and a 
name of the form 'John Doe @ State University' as a path name, it is more 
accurate to view the *@' operator as specifying one level of indirection. For 
example, if the local site's name server identifies the site principal named 'State 
University' and the local name server is found in the search path before the 
internet principal's name server, then the name 'John Doe @ State University' 
is resolved without consulting the internet principal's name server. 

Second, control over the search process is centered at the client. This is in 
keeping with the philosophy that the name space is an "end-to-end" function 
defined by the client; name servers never contact each other on behalf of a client, 
and in fact, they have no knowledge of the existence of a name space. This design 
has two important consequences. The first is that alternative name space abstrac- 
tions can be defined, each of which supports a different syntax and more or less 
restrictive searching machinery. The second is that it is easy for the client to 
terminate a search before it has completed. This might happen, for example, if 
the user is satisfied with the first answer returned. As pointed out earlier, such 
termination is essential when the client program detects a loop. 

Finally, the user can step through the confederation of name servers in a 
piecemeal fashion, rather than submit one complex profile name. For example, a 
user might resolve the simple name 'State University', extract the address of that 
principal's name server from the result, and then contact that name server with 
one or more other profile names. As another example, a user might submit the 
name 'John Doe @ Sigcomm', learn that John Doe is at State University, and 
then submit the name 'John Doe @ State University' in the hope of learning 
more attributes for John Doe from State University's name server than he or she 
was able to learn from Sigcomm' s name server. 

4. USER INTERFACE 

A user interface provides a mechanism through which users interact with Profile 
and invoke base commands in the underlying computing system. In its simplest 
form, a user interface to Profile might apply resolve to a given profile name and 
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display the resulting attributes to the user, leaving the user responsible for 
composing a resource name and applying a base command to the name. A more 
complicated user interface might fully integrate the Profile name space with the 
existing naming systems, thereby allowing the user to apply base commands to 
profile names directly. Such an interface hides the underlying systems behind 
the principal abstraction. Between these two extremes, the user might implement 
a collection of customized commands, each of which augments some base com- 
mand with a routine that takes a profile name as an argument, invokes the 
resolve operation to retrieve the set of attributes bound to the principal identified 
by the name, and translates the attributes into a resource name understood by 
the base command. For example, a customized mail command might allow a user 
to address mail to a principal rather than a mailbox; e.g., 

mail "John Doe, Computer Science, State University" 

Recognizing the common thread that runs through such customized commands, 
Profile provides a procedure-based translation mechanism that is used to con- 
struct such commands. We refer to customized commands built using the trans- 
lation mechanism as profile commands. This section gives an operational overview 
of the translation mechanism, and demonstrates how the mechanism has been 
incorporated into the UNIX csh shell [8], 

4.1 Translation Mechanism 

A profile command specification is an ordered list of conditional templates, each 
of which is a triple of the form 

(condition, cmd-name, rewrite-rule) 

A condition is a Boolean function that takes one or more attributes as arguments. 
For example, a condition that determines if a principal sponsors a Profile name 
server is a function of the profile attribute, a condition that determines if a 
principal is a user is a function of the login attribute, and a condition that 
determines if a principal's resources are contained in the local system is a function 
of the domain attribute. A cmd-name is the name of a base command that is to 
be applied to a resource. It must be understood in the local computing system. A 
rewrite-rule is a function that takes one or more attributes as arguments and 
returns a resource name. 

Suppose, for example, that a user defines a specification for a profile command 
called copy that copies files to and from a principal's home directory, and a 
specification for a profile command called mail that sends mail to a principal. 
Borrowing syntax from the C programming language [9] 3 , Figure 6 gives the 
specifications for the two profile commands, where each condition is given by a 
C procedure similar to the one presented in Figure 7. 

The translation mechanism takes a profile command specification and a set of 
attributes as arguments and returns the name of a base command and the name 
of a resource that the base command takes as an argument. Operationally, the 
translation mechanism evaluates the condition associated with each template in 
the specification according to the attributes, where the first template for which 



: * The string contained between double quotes controls C's formatted output. 
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copy = (( IocaLuser(login,domain), cp, (7r/%3s/usr/%s^home,login)); 
{ locaLsys(login,domain), cp, ("/r/meg/usr/f tp")), 

{ remote,user(login,domain), rcopy, ( M %s:%s.%s:",login,home,domain)), 
( remote.sys(login,domain), rcopy, ("anonymous-.^os^sr'Vhome^omain))) 

mail = (( IocaLuser(Iogin,domain), mail, ("^os'Vlogin)); 
{ def (login), mail, f^s'Vmail)); 
{ !def(login), mail, ("root@%s",domain))) 

Fig. 6. Example Profile command specifications. 



locaLuserdogin, domain) 
char Mogin, ♦domain; 

if (strlen(login)>0 && strcmp(domain / , 'state.edu")!=0) 
retum(TRUE) 

else 

rehirn(FALSE) 

Fig. 7. Example condition. 

the condition is satisfied yields a command name and a rewrite rule. The 
translation mechanism returns the command name and the string produced by 
applying the rewrite rule to the attributes. For example, when given the specifi- 
cation for the copy profile command and the set of attributes 

(login— jxd, name=John Doe, phone— 621-1234, mail= jxd@state.edu, 
domain = state.edu, home=megaron) 

the translation mechanism returns the command name 'cp 1 and the resource 
name 7r/meg/usr/jxd\ 

4.2 Profile Shell 

The Profile shell, pcsh, is an extended version of the UNIX csh that supports 
the specification and invocation of profile commands. Briefly, csh provides a 
command interpreter that accepts input from the user and invokes commands in 
the underlying UNIX system. Each line of input is processed by the five phases 
given in Figure 8. In addition, csh defines an environment that consists of a set 
of shell variables (e.g., a search path variable used to locate binary files that 
implement commands) and specifications for various phases of the interpreter 
(e.g., aliases used in the rewriting of commands in phase two). Pcsh extends csh 
as follows. 

First, the lexical analysis phase is modified to recognize arguments that contain, 
either totally or in part, profile names. Such names are syntactically distinguished 
with special characters; e.g., double quotes. Second, the environment is extended 
to include the three name space parameters defined in Section 3, as well as a 
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(1) Lexical Analysis 

(2) Aliases Substitution 

(3) Parse Fig. 8. Five phases of csh. 

(4) File Name Completion 

(5) Execute 

command registry that binds profile command names to their respective specifi- 
cations. Third, a new profile phase is added after the parsing phase and before 
the file name completion phase. The profile phase invokes the resolve operation 
to retrieve the set of attributes associated with any profile names tagged by the 
lexical analysis phase; retrieves the specification bound to the command name 
from the command registry; applies the translation mechanism to the attributes 
and specification; and substitutes the resulting command name and resource 
name for the original command and arguments. 

For example, given the set of attributes bound to John Doe and the profile 
command specifications for copy and mail, the input line 

copy " John Doe"/project/src/x.c y.c 
is rewritten as 

cp/r/meg/usr/jxd/project/src/xx y.c 
if John Doe is a local user, and the input line 

mail " John Doe @ State University" 
is rewritten as 

mail jxd@state.edu 

if John Doe is a remote user. In the former example, if the profile name ' John 
Doe' had identified a remote user rather than a local one, then rcopy would have 
been applied to the arguments ( jxd:megaron.state.edu:src/x.c y.c 1 , where rcopy is 
an interface to FTP [20] that takes the leftmost component of the argument 
(jxd) to be a login identifier, the intermediate component of the argument 
(megaron.state.edu) to be a host name, and the remainder of the name 
(project/src/x.c) to be a file name. In the case of a remote system, rcopy 
would have established an FTP connection to the system's guest account. 

A final note: If a command is applied to an argument that contains a profile 
name, but no specification is bound to the command, then the original argument 
is passed directly to the command. Passing uninterpreted profile names to 
commands allows more complex integration of Profile with the application. For 
example, 

mail "John Doe "©state.edu 

causes a message to be forwarded to the host identified with the domain name 
'state.edu* , where the mail program running on that host invokes a local Profile 
name server to interpret 'John Doe'. Passing profile names directly to commands 
also facilitates a profile-lookup command that provides a direct interface to 
the resolve and bind operations provided by the name space abstraction. 
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5. EXPERIENCE AND EVALUATION 

Profile has evolved to its present form over a period of two years. It currently 
runs on a testbed of three sites and has been used by several dozen users. This 
section evaluates the successes and limitations of Profile and reports how our 
experiences with Profile reflect on several issues related to attribute -based 
naming. 

5.1 Name Servers 

Profile name servers allow multiple attributes to be registered for each principal, 
support a flexible representation of attributes, and provide a suite of interpret 
functions that can be applied to attribute-based names. We have considerable 
experience with individual Profile name servers, including extensive testing 
during the development phase, comments from our user community, and the 
intuition developed while exploring the theoretical issues. Based on this experi- 
ence, we comment on the following issues. 

5.1.1 Attributes. Although Profile attributes are tagged, clients are not required 
to include the tag when they query a Profile name server. The reason is that tags 
are strings concatenated to attributes to enforce a uniqueness property [6], that 
is, to make attributes that denote different properties syntactically unique. While 
pathological examples exist, our experience strongly suggests that attributes 
denoting different properties are already unique, and therefore tags usually need 
not be included. We believe this to be the case because different types of attributes 
are inherently represented by different expressions — personal names do not look 
like street addresses, which do not look like phone numbers, and so on. Another 
way of looking at this is to say that an attribute's tag can be determined from 
the syntax of its value. Giving an attribute's tag does improve the accuracy of 
the interpret functions, however, when the attribute's value is ambiguous. For 
example, if a user knows that a principal's name begins with *S' but has no hint 
as to the correct spelling, an attribute of the form 'name=S*' is much more likely 
to produce a meaningful result that is the attribute *S*\ 

We had two objectives in mind when choosing to represent attributes by 
expressions. First, we wanted a flexible mechanism for comparing named attri- 
butes against registered attributes, thereby allowing users a wide latitude in 
specifying attributes. Second, we wanted to be able to build simple tools for 
generating attributes from available administrative data. Although expressions 
have proven adequate in both regards, it is clear that how attributes are generated, 
represented, and compared is the aspect of Profile that requires the most fine 
tuning. An example problem is the treatment of common nicknames, such as 
Doug for Douglas, Rick or Dick for Richard, and so on. One promising idea with 
which we have experimented is a mechanism that determines whether or not two 
strings (e.g., 'Doug' and 'Douglas') represent the same attribute by computing 
the ratio of the number of characters by which the two strings differ to the total 
number of characters in the strings [14], Although this technique accommodates 
simple nicknames, it is not able to detect that 'Peggy* is a nickname for 
'Margaret'. A more general solution is to write an expert system that generates 
nicknames to register in the database. Also, users can directly enter additional 
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nicknames as incomplete attributes. Finally, other possibilities that we have not 
yet explored involve the use of spelling correctors and phonetic spelling programs. 

5.1.2 Interpret Functions, We have demonstrated experimentally that Profile's 
interpret functions are an effective tool for identifying principals. Our experience 
shows, for example, that interpret is useful when the user's intent is to identify 
as wide a set of principals as possible; interpret^ is appropriate when the user 
wants to ensure that a particular principal is returned, possibly at the expense 
of multiple principals being returned; interprets offers a useful heuristic for 
pruning extra principals from the result; and interpret is appropriate when the 
user wants a unique match. Interpret^ is the function of choice for identifying a 
single principal. 

Although difficult to quantify, Profile's interpret functions appear to offer a 
richer mechanism for computing the principals identified by an attribute-based 
name than do similar white-pages naming services; e.g., X.500 [7], NICNAME 
[19], and the CSNET name server [26]. This is because Profile considers both 
the exactness of the match and the potential incompleteness and inaccuracies of 
the database. Moreover, being able to tune the behavior of a name server by 
selecting the interpret function is a strength of Profile. In regard to this latter 
point, it is not clear that a more powerful mechanism that supports arbitrary 
queries — e.g., a general relational database or the filter mechanism provided by 
X.500 — is warranted. To illustrate this point, consider that an interpret function 
can be viewed as a program that takes a set of attributes as an argument, 
constructs a specific database query, and solves it. Each of Profile's interpret 
functions is designed to a construct a useful class of queries. To achieve the same 
effect with a general database would require the user either to compose an 
extremely complex query, or to use a query language mechanism that, loosely 
speaking, implements the interpret functions. 

5.1.3 Registering Attributes. Consistent with experience from similar efforts, 
getting users to register information is the most difficult aspect of providing a 
white-pages naming service. We note, however, that by providing Profile name 
servers at the local-level rather than the internet-level, and by further distributing 
the administration of a single name server over a hierarchy of text databases, we 
have met with some success in this regard. 

It is also the case that a major success of our design is that we have been able 
to generate name server databases from existing administrative data, thereby 
freeing the name server from depending on individual users. Moreover, we are 
able to re-execute the attribute generation mechanism periodically to keep the 
database up-to-date. Finally, the possibility of one principal masquerading as 
another by registering attributes for himself or herself that really identify 
someone else is not a problem. The reason for this is that individual principals 
are only permitted to enter incomplete attributes and complete attributes are 
preferred to incomplete attributes by the interpret functions. 

5.1.4 Performance. An internal version of a database (i.e., one containing 
attributes that have been expanded) for a minimally configured Profile name 
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server (i.e., one containing only complete attributes) that is an authority for 
3,050 principals occupies approximately 30K bytes of memory. Experiments with 
the name server show that interpret^, the most complex interpret function, 
computes the set of principals that match a typical attribute-based name in 
55 msec on a VAX 8600. These results suggest that the current implementa- 
tion of a name server should be able to accommodate on the order of 10 4 princi- 
pals. A single name server should therefore be sufficient for a large university 
or company. We are currently experimenting with indexing techniques 
that we expect to allow a name server to handle on the order of 10 5 principals 
efficiently. 

5.1.5 Protection. Although not currently implemented in Profile, we under- 
stand that some protection mechanism, e.g., an access control list, is essential 
[23], Such a mechanism would allow the name server's sponsor to define different 
client classes and to permit clients in each class to invoke some subset of interpret 
functions (thereby controlling the precision with which a client must describe a 
principal before the name server returns information about the principal) and 
receive some subset of attributes for each identified principal (thereby controlling 
how much information the name server releases about each principal identified 
by the client). For example, an organization's name server might allow local users 
to invoke all the interpret functions and receive all attributes registered for any 
identified principals, but permit remote users to invoke only interpret 2 and 
interpret and receive only the name and mail attributes for any identified 
principals. Such restrictions can be applied uniformly across the entire database, 
as well as on an entry by entry basis; e.g., one principal may restrict access to 
the phone attribute and another may not. 

In addition to restricting the interpret functions that may be applied and the 
attributes that may be returned, a name server sponsor can tune the protection 
policy in two additional ways. First, the precision of attributes registered in the 
database may be varied; e.g., the attribute 'John Doe 1 might be registered as a 
person's name rather than *[J[ohn]]Doe\ The more precise the representation of 
attributes, the more exact the information presented by the client to identify a 
principal. Second, the name server can restrict the form of attributes it accepts 
from clients. For example, it can choose to not resolve attributes containing the 
**' operator. 

5.1.6 Relocation Transparency. Profile does not attempt to make the relocation 
of principals— that is, changes to the attribute values bound to them — transpar- 
ent. Our experience suggests that if the relocation of principals is to be made 
transparent, then it should be done by a lower level naming system. For example, 
to facilitate sending mail to a user principal in a relocation transparent way, one 
of the attributes returned for a user principal could be an internet-wide unique 
identifier that is in turn mapped into the user's current mailbox address by some 
independent naming service. 

Profile does support a unique handle attribute, however. A principal's handle 
is never reassigned, even if the name server is no longer an authority for the 
principal. Once a client possesses a principal's handle, for example as a result of 
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an initial query of a name server, it can reuse the handle as an attribute in 
subsequent queries of the name server to retrieve the principal's current attri- 
butes. Thus, handles are useful for refreshing the attributes bound to a principal 
in a user's alias name server. 

5.1.7 Naming Arbitrary Objects. Profile was originally designed to name a 
single type of object: principals. Clients indirectly learn the names of other 
resources by giving attributes that identify their sponsor. It is also desirable 
to allow clients to name resources by giving other attributes that describe 
the resource. This would allow a client to distinguish among a set of similar 
resources sponsored by the same principal. For example, a client might want to 
identify a local printer by submitting the attributes 'architecture=postscript', 
'pagesperminute>8\ and < load=min'. We have successfully extended a Profile 
name server to allow clients to identify arbitrary objects, including computational 
objects such as printers, processors, and databases, with any attribute that 
meaningfully describes the object [4, 17]. 

While name servers that resolve attribute-based names for computational 
objects are often referred to as yellow-page servers, our experience is that yellow- 
page and white-page servers are fundamentally the same. In particular, we are 
able to support both within the framework of the same architecture simply by 
including a new interpret function, defining alternative attribute representations 
(e.g., integers, reals, and lists in addition to expressions) and supporting indefinite 
attributes (i.e., attributes that include relational operators like < and >). It is 
also worth noting that a technique similar to the attribute generation mechanism, 
used to register attributes for principals, is used to register frequently changing 
attributes for computational objects; e.g., a processor's load. Instead of the 
conventional model of registering and explicitly updating the database with static 
values, the technique involves registering functions that compute attribute values 
dynamically and on demand. Finally, adding arbitrary objects to a Profile name 
server results in a significant number of cross-references between objects, thereby 
allowing one to give an attribute-based name for a user to learn the name of the 
user's workstation, as well as to give an attribute-based name for a workstation 
to learn the name of the user that owns the workstation. 

Adding different objects to a name server introduces one new problem: attribute 
values with the same tag but registered for different types of objects are quite 
often indistinguishable. For example, submitting the attribute -based name 
'name— john' might yield both a workstation and a user. We have, therefore, 
defined a new attribute tag, denoted is_a, that identifies the type of the object. 
However, we treat an object's is_a attribute as simply another attribute that 
describes the object: the is_a attribute need not be given to identify the object, 
but doing so improves the chances of receiving the expected answer. Note that 
the problem of the same attribute being registered for different types of objects 
is different from the point made in Section 5.1.1 that attributes for the same 
type of object need not be tagged because their values are syntactically unique. 
It is the case, however, that the argument made in 5.1.1 does not apply as well 
to computational objects as it does to principals. The reason is that different 
attributes for computational objects are often given by small integers. 
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5.2 Name Space 

Profile adopts a "library reference collection" model for its name space: name 
servers are independent naming authorities arranged in a loose confederation, 
the name space abstraction is implemented at the client, and a flexible search 
strategy is used to traverse a set of name servers. The testbed Profile name space 
contains a collection of alias name servers and five organizational name servers — 
an internet name server, three site name servers, and a name server consisting 
of the members of the ICON user's group. It is clear that the size of the testbed 
is too limited to support a thorough analysis of the name space. In particular, it 
is difficult to estimate the network load Profile would generate, and as a 
consequence of that load, identify what restrictions should be placed on the 
search strategies. On the other hand; we have demonstrated the workability of 
the name space, and we are able to offer the following preliminary evaluation 
regarding the appropriateness of the design. 

5.2.1 Performance. As indicated in Section 5.1.4, a single name server is 
capable of serving large organizations on the order of universities and companies. 
As a consequence, it is reasonable to expect a site-based collection of name 
servers and a single level of indirection to be sufficient for the current configu- 
ration of the DARPA/NSF Internet. In such an environment, the following 
performance factors are important: the alias name server can be accessed by a 
procedure call; the local site name server can be queried in under 100 msec; it 
can take several seconds to query a name server across the DARPA/NSF Internet; 
the '@' operator often implies that two remote servers need to be queried; and 
each server identified in the search path may need to be queried. The last point 
is particularly critical if the name contains an error or identifies an unknown 
principal. 

Our experience shows that the performance of resolve can be made satisfactory, 
that is, the cost of accessing a remote name server is incurred only when 
necessary, when the "find the first answer under explicit control" search strategy 
is used. To do this, the user must exploit the alias name server and take care to 
define a minimal search path. That is, the search path should include only the 
alias and local name server unless the user wants to conduct a global search. 
Although not implemented in Profile, our experience suggests that the search 
path be partitioned into "local" and "global" parts and that the user be asked to 
confirm use of the global part. 

5.2.2 Separation of Functionality. One of the most important design philoso- 
phies behind Profile is that an internet's attribute-based naming service should 
be separate from its universal name space, and that the design of one should not 
be compromised for the sake of the other. Internet universal naming systems are 
typified by the DARPA/NSF Internet's domain naming system [13]; similar 
naming systems include Lampson's global naming service [10], Lantz, Edighoffer, 
and Hitson's UDS system [11], and the Xerox Clearinghouse [16], 

Our design advocates this separation because the primary goal of a universal 
naming system is to support absolute names that can be resolved efficiently. For 

ACM Transactions on Computer Systems, Vol. 6, No. 4, November 1988. 



The Profile Naming Service • 361 



example, the domain system must map a host name into the same internet 
address for all clients, and this mapping must be performed every time a client 
establishes a connection to a host. In contrast, Profile's objective is to provide a 
flexible naming service that maximizes the possibility of the user finding a useful 
result. It does this at the expense of preserving absolute names (users share 
"descriptions" of principals rather than precise profile names) and at the expense 
of efficiency (users only engage Profile to learn resource names, not every time 
the resource is accessed). 

To realize its goals, universal naming systems generally restrict the structure 
of the name space to a hierarchy and support a simple search strategy in which 
a name denotes a path through the hierarchy. In contrast, Profile allows an 
arbitrary configuration of name servers and offers a richer search strategy. It 
does this because mandating a single hierarchical partitioning of the world forces 
the user to know enough attributes to construct a path name according to that 
partitioning. We envision name servers sponsored by professional organizations 
(e.g., ACM special interest groups and IEEE societies), mailing lists, user groups, 
and so on. Furthermore, the loose coupling of name servers allows the confeder- 
ation to evolve "bottom-up" without the need for centralized control. In such an 
environment, clients (users and system administrators) "subscribe" to those 
name servers that might be of use. 

The X.500 naming system adopts an alternative design in which the attribute- 
based name space is restricted to a hierarchy. One reason for doing this is to 
support a unique "distinguished name" for each object. X.500 accommodates 
users that have incomplete information by associating a set of attributes with 
each object, and allowing users to "browse" the attributes at each node in the 
hierarchy. Thus, to learn the distinguished name of an object for which the user 
has incomplete information, the user traverses the hierarchy one node at a time, 
browsing through the attributes at each node. 

5.3 Interface 

The user interface provides a mechanism for using information learned from 
Profile to access resources by name. The most critical factor in the design of the 
user interface is the degree of confidence the user has in Profile returning 
attributes for the principal that the user "intended" to identify with the name. 
Our experience shows that there is a spectrum of styles for interacting with 
Profile. At one extreme, the user queries Profile to learn about a certain principal. 
This is generally the case when the principal in question is a remote user. At the 
other extreme, the user trusts that a certain profile name identifies a particular 
principal, and is willing to let Profile invoke a base command on the attributes 
returned by a name server. In practice, users tend to trust their aliases, and to 
some degree, the local name server and name servers that identify organizations. 
In the middle of the spectrum, a user might be willing to let the interface apply 
a base command to an argument, but only if given a chance to confirm or abort 
the action. A related issue is the sensitivity of the command; a user might be 
willing to list the files in the home directory of the wrong principal, but not 
willing to send mail to the wrong principal. 
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Although our experience with pcsh is limited to a small user community, there 
appears to be a legitimate use for a more sophisticated interface than just 
profile. lookup command, and pcsh offers a reasonable tool with which the 
user can build such an interface. As an example of how easily the tool allows 
the user to extend the interface, by registering an attribute with the tag printer 
for each user principal with a printer in their office and defining a specification 
for a print profile command, it is easy to send output to the printer in John 
Smith's office by typing 

print "john" file.dvi 

As another example, the tool has proved useful for building commands that take 
advantage of attributes registered for objects other than principals, e.g., 

compile "is_a=processor, architecture=68020, mips>2.0, load=min" file.c 

Using a procedure-based translation mechanism to generate locally understood 
names proved to be a powerful and flexible technique for integrating the Profile 
name space with other naming systems. In particular, although the scope of the 
general problem is on the order of "number of commands X number of autono- 
mous systems," our experience shows that a small number of attributes and 
templates are sufficient in practice. We also observe that the procedure-based 
approach seems more appropriate than the table-based approach exploited by 
Schwartz, Zahorjan, and Notkin [24]. The reason for this is that the naming 
systems in which we are interested are implicitly associated with commands; 
they do not exist as segregated naming services with well-defined interfaces. 



6. CONCLUDING REMARKS 

This paper describes the Profile naming service. The novel aspects of Profile are 
its attribute-based name servers, a flexible mechanism for searching a confeder- 
ation name space, and tools that can be used to build a customized user interface. 
A prototype implementation demonstrates that Profile is a useful and effective 
mechanism for identifying principals in a limited testbed. By extrapolating from 
this experience, we conclude that Profile's confederation of attribute-based name 
servers is extendible to a full-scale internet. 

Based on our positive experience with Profile, we have used its architecture as 
a blueprint for a general protocol used to query attribute-based name servers 
[18]. Using this protocol, we plan to expand the Profile testbed to additional 
sites, including extensive coverage of the NASA Science Internet. In doing so, 
we hope to be able to address the unanswered questions regarding the name 
space search strategies. We also hope to settle on an appropriate set of conventions 
that govern how the system is to be applied and used; e.g., define a standard set 
of attributes and establish reasonable protection policies. Finally, we plan to 
continue our effort to integrate dissimilar naming systems by generalizing the 
procedure-based translation mechanism exploited by Profile. 
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APPENDIX: GRAMMAR FOR ATTRIBUTES 

This specification uses a subset of Backus-Naur Form that includes the following 
metacharacters. 

| Elements separated by bar (* | ') are alternatives. 
' 9 Encloses literal text. 

; Starts a comment that continues to the end of the line. 
::= Assignment sign; the left side is a nonterminal 
and the right side is a rule. 

attribute ::~ expression 
expression ::= attr_str 

| '[* expression *]' ; optional 

| expression ' | ' expression ; alternative 

j expression expression ; wildcard (named attribute only) 

j expression expression ; single character wildcard 

(named attribute only) 

| *(' expression *)' ; expression itself 

I empty 

attr_str ::= attr_substr | attr_substr blank attr.str 

attr_substr ::= attr_alphabet | attr_alphabet attr_substr 

attr_ alphabet ::= letter | digit | attr_sc 

attr_sc | | 7 | \ | | V | T | T |'&T ' 

letter :;=VT |...| 'Z* | V | . . . I V 

digit '0' | . . . | '9' 

blank ' ' 

; the blank character 
empty ::= " ; the empty string 
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